@mitu Awesome suggestion! I installed the latest 32bit LMDE and the install process has run successfully! Way cool on a 2008 Netbook!

@WhiteT982

Nice, thank you.

@WhiteT982
Ok so change the names and now I can exit non libretro using only my Select button. So not entirely there but I guess it will work. Once again appreciate all of the help

@chicoputo cool to see this helped someone else, somthing additional that might be be helpful.

if you re-map the controls you need to reapply the fix.

not sure what but somthing happens that causes it to default back to error state

@Crush said in Redream on x86_64:

@sleve_mcdichael would it still help you if i test that now that @BuZz will fix the tags?

Buzz will probably take care of it but it might get you up and running sooner if you don't want to wait for the fix to push through. I think 64bit is probably is the right flag to use here; looking at the other modules it's only used a couple of times, but it is used outside this particular module, while x86_64 is not (not as a module_flag, anyway. Its use for other things like as a platform identifier in this same module is still fine, I think.)

pi@retropie:~/RetroPie-Setup/scriptmodules $ grep -rni . -e module_flags | grep -e 64 ./supplementary/splashscreen.sh:16:rp_module_flags="noinstclean !all rpi !osmc !xbian !aarch64" ./libretrocores/lr-dolphin.sh:18:rp_module_flags="!all 64bit" ./libretrocores/lr-kronos.sh:18:rp_module_flags="!arm !aarch64" ./libretrocores/lr-uae4arm.sh:18:rp_module_flags="!all arm aarch64" ./libretrocores/lr-mupen64plus.sh:18:rp_module_flags="!aarch64" ./libretrocores/lr-mupen64plus-next.sh:18:rp_module_flags="" ./emulators/mupen64plus.sh:18:rp_module_flags="sdl2" ./emulators/redream.sh:17:rp_module_flags="noinstclean !all gles31 aarch64 x86_64" ./emulators/np2pi.sh:17:rp_module_flags="sdl1 !all rpi !aarch64" ./emulators/dolphin.sh:18:rp_module_flags="!all 64bit" ./ports/solarus.sh:18:rp_module_flags="!aarch64" ./ports/love.sh:18:rp_module_flags="!aarch64" ./ports/love-0.10.2.sh:18:rp_module_flags="!aarch64"

According to the libretro docs, yes, that folder should be created. However, the same page says that internal Dolphin cheats are not supported, so that step may be useless.

@mitu happy to report that after installing 20.04 on another HD I am able to natively use my controllers in the menus. Now to go through the process of redoing all the OS tweaks.

Thanks for all your help @mitu

Modify the emulators.cfg file from /opt/retropie/configs/wii and add a new emulator entry for the distro's version of dolphin. You can then choose this version from the runcommand launch menu and make it the default for running Wii games.

One game I cannot get to work even with flycast is Hydro Thunder. I get a black screen after the Dreamcast logo.

@oskeeeddie Re-install/Re-enable the RetroPie shares from the RetroPIe-Setup script and see if you get all 3 shares back.

@mitu alright thanks ill give that a shot

@mitu when the crash happen, i hard reset then restart the system as i can't get a tty in a freeze status.. so i go like you suggest me to get log from /dev/shm/runcommand.olg but i can't find nothing. infact as sometime get no crash i find there the log without error as a list the operation in the retropie like type of emulator rom launched etc. so crash without log or log without crash.
i can't go further..infact i can't understand what happened different when one time things go perfect ( sometime i change the kernel ... but second chances to run other rom all crash so i think is not depending on this ) i don't know if depend on using a particular type of emulator : neo geo or version of mame and i don't know, it's own configuration ( video settings, audio .. ) but i can't get log after crash ... so i dont know to proceed to fix. have a nice day and thnx for all the detailed reply.

I got this resolved on my system (Ubuntu 18.04, Intel i5-3470 iGPU) by installing and using Vulkan rendering. I did not have to download the Sys folder from the Dolphin source repo.

I must note that Vulkan is not supported on any CPU earlier than Ivy Bridge, so this may not be a viable solution for some people. Mine is the earliest possible generation chip this even works on, so I guess I got lucky.

Install Vulkan support and testing application

sudo apt install -y mesa-vulkan-drivers vulkan-utils

Test Vulkan (successful example):

vulkan-smoketest

Modify the GC and Wii cores' config files to use Vulkan renderer:

sed -i '$ i\video_driver = "vulkan"' /opt/retropie/configs/wii/retroarch.cfg sed -i '$ i\video_driver = "vulkan"' /opt/retropie/configs/gc/retroarch.cfg

After doing this, GC games worked fine. I'll come back and modify this post if necessary whenever I get around to adding Wii to my system.

I don't understand why you think there should be an Emulationstation folder in you $HOME after you install the package through the RetroPie-Setup - the installation folders for all packages are in /opt/retropie. After installation, you should be able to start Emulationstation using the RetroPie shortcut (.desktop) file added by the installer.

@mitu perfect thank you!

@mitu said in How does one make a script module for an emulator / branch:

@HoJo215 said in How does one make a script module for an emulator / branch:

DRI3 was the problem.

Isn't this a runtime settings for your X.org configuration ?

Actually I think it's part of the graphics or at least shader profile being used in mesa.
I have padoka's bleeding edge repository in use.. Otherwise known as unstable.
So things can go awry.. Like they did until I took a gander at the Makefile, saw some unused options, put 1 + 1 together and made some edits.. It worked a out beautifully.
Especially on the Flycast-Wince emu with the same Makefile edits. I'm playing Sega Rally 2 on 2x internal resolution, 2x br and a 4x pass xbr shaders without one hiccup.

Keep in mind this my first run with retropie x86. I decided to make small form factor emu box a month or so ago and gripped up a coffee lake NUC to guinea pig with. So everything is trial & error as I run with it.

To reply to my own post with more info...I believe this to be a bug with the Mednafen core and/or Retroarch. Possibly moreso Retroarch

Using the Vulkan renderer worked great for a while then all the sudden mid game my battle swirl went away and all i get now is a black screen with this as well. Same with the GL renderer as mentioned before if this is what you're reading. I replicated the same scenario with another device as well...

The swirls work fine initially then stopped working entirely for some unknown cause however i was reading this issue which had a very valid workaround:
Github-beetle

If on both OpenGL and Vulkan you want your battle swirlies and they just stopped working start the game, toggle ANY option on and off in Retroarch then resume the game and everything is fine. I cant believe i had not even tried that even by accident...

Edit: I ended up recording a video of this along with what actually works as a fix. Keep in mind there are NO core overrides and this is with stock retroarch settings which use OpenGL.

UPDATE: Thank you guys! Indeed Ubuntu was set to 4K, changed it to 1920x1080 60hz and it instantly solved the issue. Facepalm Rookie mistake! lol! I appreciate everyones help!